Systems and Methods for Controlling Data Access in Client-Side Encryption

ABSTRACT

Systems and methods for controlling access to data in applications using client-side encryption. In that regard, in some examples, a first application (e.g., an email application, calendar application, messaging application, word processing application, file storage application, etc.) hosted from a particular web domain may be configured to invoke a second application hosted from a different origin (e.g., a different web domain or subdomain) to handle receiving and encrypting any sensitive information from a client entered through a client application (e.g., a web browser), and to handle decrypting information to be provided to the client through the client application. This second application may be loaded in an inline frame or similar subwindow or subroutine configured to prevent or limit the first application from having access to sensitive information in the second application.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.17/320,880, filed May 14, 2021, which claims the benefit of the filingdate of U.S. Provisional Application No. 63/179,765, filed Apr. 26,2021, the disclosure of which is hereby incorporated by referenceherein.

BACKGROUND

Many online applications allow or require that data entered by a clientor displayed to a client be encrypted. However, those same applicationsmay also interface with scripts or components that do not have a needfor any of that encrypted data. In some cases where encrypted content isdisplayed in a web page, such other scripts may be hosted from the sameorigin as the parent application, and thus may be able to access thedocument object model (“DOM”) of the page, which in turn gives thescripts access to all of the content on the parent application. Forexample, an online mail application at mail.website.com may beconfigured to handle encrypted emails and attachments, but may also beconfigured to interface with a different widget hosted from the sameorigin (mail.website.com) that provides additional features such as theability to schedule emails to be sent at a later time.

BRIEF SUMMARY

The present technology concerns systems and methods for controllingaccess to data in applications using client-side encryption. In thatregard, a first application (e.g., an email application, calendarapplication, messaging application, word processing application, filestorage application, etc.) hosted from a particular web domain may beconfigured to invoke a second application hosted from a different origin(e.g., a different web domain or subdomain) to handle receiving andencrypting any sensitive information from a client entered through aclient application (e.g., a web browser), and to handle decryptinginformation to be provided to the client through the client application.This second application may be loaded in an inline frame or similarsubwindow or subroutine. In some aspects, by hosting the secondapplication from a different origin than the first application, thefirst application and its scripts can be prevented from having access tothe information in the second application (e.g., in some cases, thefirst application will not have access to the second application's DOM),and thus will not be able to access any sensitive information in itsunencrypted form. In this way, the second application can act as asandboxed intermediary between the client application and the firstapplication.

In one aspect, the disclosure describes a computer-implemented methodcomprising, in response to a request to a first application to encryptfirst data from a client application: configuring, using one or moreprocessors of a processing system, a second application such that thesecond application can store the first data without the firstapplication having access to the first data as stored by the secondapplication; encrypting, using the one or more processors according tothe second application, the first data into second data; andtransmitting the second data from the second application to the firstapplication. In some aspects, the first data comprises text, one or morefiles, or both the text and the one or more files. In some aspects, thefirst application is an email application, calendar application,messaging application, or file storage application. In some aspects, thefirst application comprises a webpage. In some aspects, the secondapplication comprises an inline frame within the webpage. In someaspects, the second application further comprises an encrypterconfigured to encrypt the first data into the second data. In someaspects, the webpage is from a first origin and the inline frame is froma second origin. In some aspects, the first origin and the second originrepresent different web domains. In some aspects, the first origin andthe second origin represent different web subdomains of a common webdomain. In some aspects, the client application comprises a web browser.

In another aspect, the disclosure describes a computer-implementedmethod comprising, in response to receiving encrypted first data at afirst application: configuring, using one or more processors of aprocessing system, a second application such that the second applicationcan decrypt the first data into second data without the firstapplication having access to the second data; decrypting, using the oneor more processors according to the second application, the first datato generate the second data; and using the second application, providethe second data to a client application. In some aspects, the first datacomprises text, one or more files, or both the text and the one or morefiles. In some aspects, the first application is an email application,calendar application, messaging application, or file storageapplication. In some aspects, the first application comprises a webpage.In some aspects, the second application comprises an inline frame withinthe webpage. In some aspects, the second application further comprises adecrypter configured to decrypt the first data to generate the seconddata. In some aspects, the webpage is from a first origin and the inlineframe is from a second origin. In some aspects, the first origin and thesecond origin represent different web domains. In some aspects, thefirst origin and the second origin represent different web subdomains ofa common web domain. In some aspects, the client application comprises aweb browser.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a functional diagram of an example system in accordance withaspects of the disclosure.

FIG. 2A shows an exemplary parent application window, in accordance withaspects of the disclosure.

FIG. 2B shows an exemplary parent application window with an inlineframe, in accordance with aspects of the disclosure.

FIG. 3 shows a flow diagram of an exemplary process for handling thedecryption and display of an encrypted message and attachment, inaccordance with aspects of the disclosure.

FIGS. 4A and 4B show a flow diagram of an exemplary process for handlingthe encryption, display, and saving of a new message and attachment, inaccordance with aspects of the disclosure.

FIG. 5 shows a flow diagram of an exemplary process for transitioningfrom an encrypted drafting mode to an unencrypted drafting mode, inaccordance with aspects of the disclosure.

FIG. 6 shows a flow diagram of an exemplary process for using a secondapplication to encrypt data from a client application and to provide theencrypted data to a first application, in accordance with aspects of thedisclosure.

FIG. 7 shows a flow diagram of an exemplary process for using a secondapplication to decrypt data received by a first application and toprovide the decrypted data to a client application, in accordance withaspects of the disclosure.

DETAILED DESCRIPTION

The present technology will now be described with respect to thefollowing exemplary systems and methods.

Example Systems

FIG. 1 schematically illustrates an arrangement 100 with an exemplaryprocessing system 102 for performing the methods described herein. Inthe example of FIG. 1 , the processing system 102 comprises two servers102 a and 102 b, each of which include one or more processors 104 a, 104b, and memory 106 a, 106 b storing instructions 108 a, 108 b and data110 a, 110 b. In the first server, data 110 a includes a parent webpage112, and one or more widgets 114. In the second server, data 110 bincludes an inline frame or “iframe” 116, which in turn includes aclient-side encryption API 118 (“CSE API”). In this regard, iframe 116represents content which may be embedded in another webpage using aninline frame element. For example, the HTML of parent webpage 112 mayinclude an inline frame element that causes the content of iframe 116 tobe embedded inside an inline frame of webpage 112 when loaded by aclient's web browser.

Processing system 102 may be resident on a single computing device, inwhich case servers 102 a and 102 b may be software servers resident on asingle computing device. Likewise, processing system 102 may be residenton a server farm, cloud computing system, or other distributed system,in which case server 102 a and 102 b may be distributed across two ormore different physical computing devices.

In the example of FIG. 1 , processing system 102 is in communicationwith one or more networks 120, through which it can communicate with aclient computing device 104, and an additional processing system 122.Client computing device 104 may be any type of computing device such asa desktop, laptop, smart phone, tablet, etc. As explained further below,client computing device 104 may be configured to run a clientapplication (e.g., a web browser). The client computing device 104 maybe further configured to load a first application (e.g., an emailapplication, calendar application, messaging application, wordprocessing application, file storage application, etc.) from parentwebpage 112 hosted by server 102 a, as well as a second application(e.g., for receiving and encrypting any sensitive information from aclient entered through the client application, decrypting information tobe provided to the client application through the client application,etc.) from iframe 116 hosted by server 102 b.

Additional processing system 122 may be another server or collectionthereof, such as a third-party website with which the one or morewidgets 114 communicate, a destination server to which the parentwebpage 112 is sending a message, a cloud storage system or database,etc. Like processing system 102, processing system 122 also has one ormore processors 124 and memory 126 storing instructions 128 and data130.

Processing system 102 may be implemented on any type of computingdevice(s), such as any type of general computing device, server, or setthereof, and may further include other components typically present ingeneral purpose computing devices or servers. Memory 106 a and 106 bstores information accessible by the one or more processors 104 a and104 b, including instructions and data that may be executed or otherwiseused by the processor(s) 104 a and 104 b. Memory 106 a and 106 b may beof any non-transitory type capable of storing information accessible bythe processor(s) 104 a and 104 b. For instance, memory 106 a and 106 bmay include a non-transitory medium such as a hard-drive, memory card,optical disk, solid-state, tape memory, or the like. Computing devicessuitable for the roles described herein may include differentcombinations of the foregoing, whereby different portions of theinstructions and data are stored on different types of media.

In all cases, the computing devices described herein may further includeany other components normally used in connection with a computing devicesuch as a user interface subsystem. The user interface subsystem mayinclude one or more user inputs (e.g., a mouse, keyboard, touch screenand/or microphone) and one or more electronic displays (e.g., a monitorhaving a screen or any other electrical device that is operable todisplay information). Output devices besides an electronic display, suchas speakers, lights, and vibrating, pulsing, or haptic elements, mayalso be included in the computing devices described herein.

The one or more processors included in each computing device may be anyconventional processors, such as commercially available centralprocessing units (“CPUs”), graphics processing units (“GPUs”), tensorprocessing units (“TPUs”), etc. Alternatively, the one or moreprocessors may be a dedicated device such as an ASIC or otherhardware-based processor. Each processor may have multiple cores thatare able to operate in parallel. The processor(s), memory, and otherelements of a single computing device may be stored within a singlephysical housing, or may be distributed between two or more housings.Similarly, the memory of a computing device may include a hard drive orother storage media located in a housing different from that of theprocessor(s), such as in an external database or networked storagedevice. Accordingly, references to a processor or computing device willbe understood to include references to a collection of processors orcomputing devices or memories that may or may not operate in parallel,as well as one or more servers of a load-balanced server farm orcloud-based system.

The computing devices described herein may store instructions capable ofbeing executed directly (such as machine code) or indirectly (such asscripts) by the processor(s). The computing devices may also store data,which may be retrieved, stored, or modified by one or more processors inaccordance with the instructions. Instructions may be stored ascomputing device code on a computing device-readable medium. In thatregard, the terms “instructions” and “programs” may be usedinterchangeably herein. Instructions may also be stored in object codeformat for direct processing by the processor(s), or in any othercomputing device language including scripts or collections ofindependent source code modules that are interpreted on demand orcompiled in advance. By way of example, the programming language may beC #, C++, JAVA, PYTHON, or another computer programming language.Similarly, any components of the instructions or programs may beimplemented in a computer scripting language, such as JavaScript, PHP,ASP, or any other computer scripting language. Furthermore, any one ofthese components may be implemented using a combination of computerprogramming languages and computer scripting languages.

Example Methods

In addition to the systems described above and illustrated in thefigures, various operations will now be described.

FIG. 2A shows an exemplary parent application window 202 in which theparent application is an email application, in accordance with aspectsof the disclosure. More specifically, FIG. 2A shows an example of howthe parent application window 202 may appear on a client's web browserwhile the client is composing a message with encryption turned off. Inthat regard, the composition window 204 shows an example messageaddressed to recipient@website.com, with a subject of “Hey,” and messagetext of “Hey there. How are you doing?” In addition, at the top right ofcomposition window 204, there is an encryption status indicator 206showing that encryption is off in this example. In the example of FIG.2A, the composition window 204 and its associated text are hosted fromthe same origin (mail.website.com) as the parent window 202.

FIG. 2B shows the same parent application window 202 as FIG. 2A, butshows an example of how the parent application window 202 may appearwhile the client is composing a message with encryption turned on, inaccordance with aspects of the disclosure. In that regard, thecomposition window 204 is displayed from within an inline frame 208hosted from a different origin of cse-mail.website.com. Although forclarity of illustration, the example of FIG. 2B shows the iframe 208 ashaving a visible boundary, it may be invisible such that the compositionwindow 204 of FIG. 2B appears to be the same size and shape as thecomposition window 204 of FIG. 2A. Further, although this exampleassumes that iframe 208 will be hosted from a subdomain of example.com(cse-mail.website.com), in some aspects of the technology, it may behosted from a completely different domain (e.g., iframe 208 could beserved from an address having a completely different root domain). Hereagain, FIG. 2B shows an example message addressed torecipient@website.com, with a subject of “Hey,” and message text of “Heythere. How are you doing?” However, at the top right of compositionwindow 204, the encryption status indicator 206 shows that encryption isturned on in this example. In some aspects of the technology, there maybe no visible indicator to show that encryption has been turned on oroff. Likewise, the encryption indicator 206 may be included in a portionof the parent application window 202 outside of composition window 204and/or iframe 208.

FIG. 3 shows a flow diagram of an exemplary process 300 for handling thedecryption and display of an encrypted message and attachment, inaccordance with aspects of the disclosure. In that regard, FIG. 3 showshow data flows between a parent application 302, an iframe 304, and aclient-side encryption API (“CSE API”) 306. Here again, parentapplication 302 is hosted from mail.website.com, and the iframe 304 ishosted from a different origin of cse-mail.website.com. CSE API 306 maybe hosted from cse-mail.website.com, or another location with whichcse-mail.website.com is in communication. In order to provideclient-side encryption, iframe 304 and CSE API 306 will be runninglocally on a client device (e.g., client computing device 104), and maybe running on the client device within a further client application suchas a web browser. Parent application 302 may also be running locally onthe client device, and may likewise be running within a clientapplication such as a web browser. However, in some aspects of thetechnology, parent application 302 may be running on a remote computingsystem (e.g., server 102 a), such that the operations of parentapplication 302 shown in FIG. 3 are performed on the remote computingsystem.

Each action shown in the example of FIG. 3 will be described withrespect to its associated bold-faced number. Thus, as shown in step 1,exemplary process 300 begins with the parent application 302 opening aniframe for an encrypted message that a user has selected for display. Inthis case, it is assumed that the parent application 302 is an emailapplication. It is further assumed that the parent application 302 willopen the iframe 304 at a location specific to the message to bedecrypted, and the conversation to which it belongs. As a result, theparent application 302 is shown opening the iframe 304 atcse-mail.website.com/conversationIDmessageID, where “conversationID” and“messageID” may be any suitable format for identifying the particularconversation and message.

In step 2 of FIG. 3 , once the iframe 304 is finished loading, itindicates this to the parent application 302. In this example, it isassumed that the iframe 304 does this by sending a CSE Editor StateMessage indicating the state of the CSE Editor as “LOADED.” However, anysuitable type and format of message may be used.

In step 3 of FIG. 3 , the parent application 302 sends iframe 304 datafor setting up a decrypter. This decrypter configuration data may be inany suitable format for identifying how to decrypt the content of theencrypted message. In some aspects of the technology, the decrypterconfiguration data may be a single file (e.g., “DecrypterConfig”) thatidentifies the type and version of encryption algorithm to use, and theencryption key or an encryption key reference.

In step 4 of FIG. 3 , the iframe 304 sends a request to CSE API 306requesting that a decrypter be created. This request will include or bebased on the decrypter configuration data that was provided in step 3.

In step 5 of FIG. 3 , the CSE API 306 will create the decrypter and passit to iframe 304. In some aspects of the technology, the CSE API 306will use an encryption key reference to get an encryption key from a keyservice (which may be local or external). The encryption key will thenbe passed to a function to create the decrypter. This decrypter may bepassed to iframe 304 in any suitable way, such as by the CSE API 306passing executable code to iframe 304, by CSE API 306 loading thedecrypter into memory and providing an identifier (e.g., a filename,function name, script element, etc.) of that program to iframe 304, etc.

In step 6 of FIG. 3 , once the decrypter has been initialized and isready to accept encrypted content, the iframe 304 indicates this to theparent application 302. In this example, it is assumed that the iframe304 does this by sending another CSE Editor State Message indicating thestate of the CSE Editor as “INITIALIZED.” However, any suitable type andformat of message may be used.

In step 7 of FIG. 3 , the parent application 302 sends the encryptedtext of the message to the iframe 304. In step 8 of FIG. 3 , the iframe304 then decrypts this text using the decrypter, and displays it to theuser. In that regard, the iframe 304 may display the decrypted text tothe user by providing the decrypted text in a format such that it can bedisplayed to the user by a client application (e.g., as HTML content tobe displayed on the user's web browser). Similar to the example of FIG.2B, the boundaries of the iframe 304 may be invisible, resulting in thisdecrypted text appearing to be displayed within a portion of the windowbelonging to the parent application 302.

In step 9 of FIG. 3 , the user clicks on a link within iframe 304 whichrepresents an attachment. Here as well, the user may interact with thislink through a client application such as a web browser. In the exampleof FIG. 3 , it is assumed that this link was included within theencrypted text of the message which the parent application 302 sent tothe iframe 304 in step 7. However, in some aspects of the technology,the parent application 302 may be configured to identify attachments toa message separately from sending the encrypted message text.

In step 10 of FIG. 3 , once the attachment link has been clicked (orotherwise selected), the iframe 304 sends a download request to theparent application 302. This download request may take any suitableformat. For example, in some aspects of the technology, the downloadrequest may be a simple message identifying an attachment ID of the fileto be downloaded.

In step 11 of FIG. 3 , the parent application 302 downloads theencrypted attachment, and passes it to the iframe 304. This may be donein any suitable way. For example, in some aspects of the technology, theparent application 302 may load the encrypted attachment into memory andprovide the iframe 304 with the filename and directory of the encryptedattachment. In some aspects of the technology, the parent application302 may send the content of the encrypted attachment directly to theiframe 304, either as a file or object (e.g., an ArrayBuffer reference).

In step 12 of FIG. 3 , the iframe 304 will decrypt the attachment usingthe decrypter, and provide it to the user (e.g., by providing it to aclient application such as a web browser). In that regard, the iframe304 may be configured to automatically prompt the user to select adownload location to which the attachment will be saved. However, insome aspects of the technology, the iframe 304 may also be configured todisplay the decrypted attachment to the user within the iframe. Forexample, where the attachment is a document with readable text, the textof the document may be displayed within a viewer inside of the iframe304. Likewise, where the attachment is photograph, audio file, or videofile, the iframe 304 may be configured to display or play the filewithin the iframe 304.

FIGS. 4A and 4B show a flow diagram of an exemplary process 400 forhandling the encryption, display, and saving of a new message andattachment, in accordance with aspects of the disclosure. As with FIG. 3, the flow diagrams of FIGS. 4A and 4B show how data flows between aparent application 402, an iframe 404, and a CSE API 406. Here as well,parent application 402 is hosted from mail.website.com, the iframe 404is hosted from a different origin of cse-mail.website.com, and CSE API406 may be hosted from cse-mail.website.com, or another location withwhich cse-mail.website.com is in communication. Likewise, in order toprovide client-side encryption, iframe 404 and CSE API 406 will berunning locally on a client device (e.g., client computing device 104),and may be running on the client device within a further clientapplication such as a web browser. Here again, parent application 402may be running locally on the client device (including within a clientapplication such as a web browser), or may be running on a remotecomputing system (e.g., server 102 a), such that the operations ofparent application 402 shown in FIGS. 4A and 4B are performed on theremote computing system. As with FIG. 3 , each action in FIGS. 4A and 4Bwill be described with respect to its associated bold-faced number.

As shown in step 1 of FIG. 4A, exemplary process 400 begins with theparent application 402 opening an iframe for receiving and encryptingtext input by a user. Here again, it is assumed that the parentapplication 402 is an email application. It is further assumed that theparent application 402 will open the iframe 404 at a location specificto the draft message being composed. As a result, the parent application402 is shown opening the iframe 404 at cse-mail.website.com/draft, where“draft” may be any suitable format for identifying the particular draft.

In step 2 of FIG. 4A, once the iframe 404 is finished loading, itindicates this to the parent application 402. In this example, it isassumed that the iframe 404 does this by sending a CSE Editor StateMessage indicating the state of the CSE Editor as “LOADED.” However, anysuitable type and format of message may be used.

In step 3 of FIG. 4A, the parent application 402 sends iframe 404 datafor setting up an encrypter. This encrypter configuration data may be inany suitable format for identifying how to encrypt the content of themessage being composed (and any files that may be attached). In someaspects of the technology, the encrypter configuration data may be asingle file (e.g., “EncrypterConfig”) that identifies the type andversion of encryption algorithm to use, and the encryption key. Althoughthe example of FIG. 4A assumes that the parent application 402 willspecify the encrypter configuration, in some aspects of the technology,the iframe 404 may instead be configured to specify the type and versionof encryption algorithm to use, and the encryption key to be used. Insuch a case, the iframe 404 may then communicate the chosen encrypterconfiguration data to the parent application 402.

In step 4 of FIG. 4A, the iframe 404 sends a request to CSE API 406requesting that an encrypter be created. This request will include or bebased on the encrypter configuration data that was provided in step 3.

In step 5 of FIG. 4A, the CSE API 406 will create the encrypter and passit to iframe 404. This may be done in any suitable way, such as by theCSE API 406 passing executable code to iframe 404, by CSE API 406loading the encrypter into memory and providing an identifier (e.g., afilename, function, script element, etc.) of that program to iframe 404,etc.

In step 6 of FIG. 4A, once the encrypter has been initialized and isready to accept content to be encrypted, the iframe 404 indicates thisto the parent application 402. In this example, it is assumed that theiframe 404 does this by sending the parent application 402 data forsetting up a decrypter. As above, this decrypter configuration data maybe in any suitable format for identifying how to decrypt the content ofencrypted messages. In some aspects of the technology, the decrypterconfiguration data may be a single file (e.g., “DecrypterConfig”) thatidentifies the type and version of encryption algorithm to use, and theencryption key or an encryption key reference. However, in some aspectsof the technology, decrypter configuration data may not be provided atthis time. In that regard, any other suitable type and format of messagemay be used by the iframe 404 to indicate its readiness to acceptcontent to be encrypted. For example, in some implementations, theiframe 404 may indicate its readiness by sending another CSE EditorState Message indicating the state of the CSE Editor as “INITIALIZED.”

In step 7 of FIG. 4A, the parent application 402 sends the existingplain text content of the message to the iframe 404. If the user has notyet entered any text prior to selecting to compose in encrypted mode,this plain text may only include the default fields of the message(e.g., to, from, cc, bcc, subject, body) and/or related content (e.g.,the template of the message, any associated html). In this example, itis assumed that the user has not uploaded any attachments prior toselecting to compose in encrypted mode. However, if the user uploads oneor more attachments prior to selecting to compose in encrypted mode, theparent application may also transmit the attachment to the iframe 404for encryption. In such a case, the iframe 404 and parent application402 may be configured to process these initial attachments using thesame flow described below with respect to steps 15-18.

In step 8 of FIG. 4A, the iframe 404 encrypts the plain text content(that which was received in step 7) using the encrypter. The iframe 404also displays this plain text to the user. Here as well, the iframe 404may display the plain text to the user by providing the plain text in aformat such that it can be displayed to the user by a client application(e.g., as HTML content to be displayed on the user's web browser).Similar to the example of FIG. 2B, the boundaries of the iframe 404 maybe invisible, resulting in this plain text appearing to be displayedwithin a portion of the window belonging to the parent application 402.

In steps 9 and 10 of FIG. 4A, the iframe 404 passes the encrypted text(created in step 8) back to the parent application 402, where it issaved. The same continues as the user enters further text into the bodyof the email (now hosted by iframe 404). Here as well, the user's inputsmay be conveyed to the iframe 404 by a client application such as a webbrowser. Thus, as shown in steps 11-13, after the user enters furthertext into the body (step 11), the iframe 404 encrypts that newly enteredtext and sends it back to the parent application 402 (step 12), where itis saved (step 13). The iframe 404 may be configured to send encryptedtext back to the parent application 402 in real-time or on any suitableinterval (e.g., every second, every 15 seconds, every minute, etc.).

Maintaining an encrypted copy of the message in parent application 402may be beneficial for a variety of reasons. For example, in some aspectsof the technology, this may be done for backup purposes (e.g., parentapplication 402 may store the encrypted copy of the draft message in adrafts folder). Likewise, in some aspects of the technology, this may bedone to allow widgets (e.g., widget(s) 114) that are not dependent uponthe content of the message to continue to function even if they arehosted in the same origin as the parent application 402 and thus lackaccess to the DOM of the iframe 404. However, in some aspects of thetechnology, it may not be necessary to store an encrypted copy of themessage in the parent application 402. In such a case, steps 9, 10, 12,and 13 may be omitted.

In step 14 of FIG. 4B, the user uploads an attachment to the message. Asthe steps of FIG. 4B follow those of FIG. 4A, this takes place in theencrypted drafting mode. As such, the attachment is uploaded directly toiframe 404.

In steps 15 and 16 of FIG. 4B, once the attachment is uploaded, theiframe 404 encrypts the attachment using the encrypter (step 15), andsends the resulting encrypted attachment to the parent application 402(step 16).

In steps 17 and 18 of FIG. 4B, once the parent application 402 receivesthe encrypted attachment, it saves it (step 17) and sends an identifierfor the encrypted attachment back to the iframe 404 (step 18). Thisidentifier may be a message of any type or format suitable foridentifying the attachment. In some aspects of the technology, theiframe 404 may not be configured to maintain a copy of the unencryptedattachment. In such a case, if the user requests to download or view acopy of the attachment (e.g., by a clicking a link to confirm that theright attachment was uploaded), the iframe 404 may use the attachment IDto obtain a copy of the encrypted attachment from the parentapplication, and may decrypt the attachment as described above withrespect to steps 3-5 and 9-12 of FIG. 3 .

FIG. 5 shows a flow diagram of an exemplary process 500 fortransitioning from an encrypted drafting mode to an unencrypted draftingmode, in accordance with aspects of the disclosure. As such, theexemplary process 500 may be used to transition from the encrypteddrafting mode represented in FIGS. 4A and 4B (following initializationsteps 1-7) to an unencrypted drafting mode in which the user's inputsare received directly by the parent application 402 and are notunencrypted.

As with FIGS. 3, 4A, and 4B, the flow diagram of FIG. 5 shows how dataflows between a parent application 502, an iframe 504, and a CSE API506. Here again, it is assumed that the parent application 502 is anemail application hosted from mail.website.com, that the iframe 504 ishosted from a different origin of cse-mail.website.com, and that the CSEAPI 506 may be hosted from cse-mail.website.com, or another locationwith which cse-mail.website.com is in communication. Likewise, it isassumed that iframe 504 and CSE API 506 will be running locally on aclient device (e.g., client computing device 104), and may be running onthe client device within a further client application such as a webbrowser. Here again, parent application 502 may be running locally onthe client device (including within a client application such as a webbrowser), or may be running on a remote computing system (e.g., server102 a), such that the operations of parent application 502 shown in FIG.5 are performed on the remote computing system. As with FIGS. 3, 4A, and4B, each action in FIG. 5 will be described with respect to itsassociated bold-faced number.

As shown in step 1 of FIG. 5 , exemplary process 500 begins with a userrequesting to exit the encrypted drafting mode. This may be done in anysuitable way, such as by clicking a button to turn off or deselectencryption. For example, in the context of the exemplary page layouts ofFIGS. 2A and 2B, the user may click on (or otherwise select) an area ofthe interface associated with encryption indicator 206 to toggle it from“ON” (as shown in FIG. 2B) to “OFF” (as shown in FIG. 2A). As above, theuser may submit this request using a client application such as a webbrowser.

In step 2 of FIG. 5 , once the request to exit the encrypted draftingmode is received, the iframe 504 sends the unencrypted plain text of themessage to the parent application so that composition can continue therein an unencrypted drafting mode.

In step 3 of FIG. 5 , the iframe 504 indicates the user's request toenter unencrypted drafting mode to the parent application 502. In thisexample, it is assumed that the iframe 504 does this by sending a CSEEditor State Message indicating the state of the CSE Editor as “PAUSED.”However, any suitable type and format of message may be used.

In step 4 of FIG. 5 , the user continues entering text into the emailbody. As the encrypted drafting mode has been paused, this newly enteredtext is received directly by the parent application 502. Again, theuser's text may be conveyed to the parent application 502 by a clientapplication such as a web browser.

Although not reflected in the exemplary flow of FIG. 5 , if the userlater chooses to reenter encrypted drafting mode, the parent application502 may transition control of the drafting over to the iframe 504 usingthe same process flow described above with respect to FIGS. 4A and 4B.In that regard, if the iframe 504 is configured to maintain theencrypter in memory after being paused (as described in step 3 of FIG. 5), then the parent application 502 may transition back to iframe 504 bysimply sending the existing plaintext back to the iframe (as describedin step 7 of FIG. 4A).

FIG. 6 shows a flow diagram of an exemplary process for using a secondapplication to encrypt data from a client application and to provide theencrypted data to a first application, in accordance with aspects of thedisclosure. The steps of method 600 may thus be performed by one or moreprocessors of a processing system (e.g., client computing device 104and/or processing system 102 of FIG. 1 ) in response to a request to afirst application to encrypt first data transmitted (or to betransmitted) by a client application. Method 600 may be applied to anysuitable context. For example, the first application may be an emailapplication, calendar application, messaging application, wordprocessing application, file storage application, or any otherapplication in which encrypting content from a client application may bedesired. In some aspects of the technology, the first application maycomprise a webpage, and the client application may comprise a webbrowser. In some aspects of the technology, the first application,second application, and client application may all be running on thesame computing device (e.g., a client device such as client computingdevice 104 of FIG. 1 ). In some aspects of the technology, the secondapplication and client application may be running on a client computingdevice (e.g., client computing device 104 of FIG. 1 ), while the firstapplication may be running on a remote computing device (e.g., server102 a of FIG. 1 ).

In that regard, in step 602, the processing system configures a secondapplication such that the second application can store the first datawithout the first application having access to the first data as storedby the second application. As noted above, this may be done in anysuitable way. For example, in some aspects of the technology, the firstapplication may comprise a webpage, and the second application maycomprise an iframe within the webpage. In some aspects, the iframe mayfurther comprise an associated encrypter (e.g., a function or programconfigured to perform encryption). In some aspects, the webpage and theiframe may have different origins from one another, such as differentweb domains or subdomains such that the first application (and anyscripts running thereon) do not have access to the DOM of the secondapplication. In some aspects of the technology, the second applicationmay comprise a subwindow or subroutine configured such that the firstapplication does not have access to the first data once it is receivedby the second application.

In step 604, the first data is received at the second application. Thesecond application may receive the first data directly from the clientapplication, or through one or more intermediaries. In that regard, insome aspects of the technology, the first application may be configuredto receive and forward the first data to the second application withoutaccessing or retaining access to the first data.

In step 606, the second application encrypts the first data to generatesecond data. The second application may do this using any suitableencryption method. Further, as noted above, the second application maycomprise an encrypter for encrypting the first data into second data, ormay be configured to call a separate encrypter application to performthis task.

In step 608, the second application transmits the second data to thefirst application. As noted above, once received, the first applicationmay be configured to store the second data, transmit it to anothercomputing system, etc. For example, where the first application is anemail or messaging application, the first application may be configuredto maintain a backup copy of the second data (e.g., locally or at aremote server) while the email or message is being composed, and may beconfigured to transmit the second data to another computing system whenthe client application indicates that an email or message containing thesecond data is to be sent to a recipient. Likewise, where the firstapplication is a calendar application, the first application may beconfigured to maintain a copy of the second data (e.g., locally or at aremote server) while a calendar entry is being created, may beconfigured to transmit the second data to another computing system whenthe client application indicates that a calendar invitation containingthe second data is to be sent to a recipient, and may (e.g., after thecalendar entry has been created) be configured to provide the seconddata back to the client application when requested (e.g., for decryptionby the second application). Further, where the first application is afile storage application (e.g., a cloud storage application), the firstapplication may be configured to store the second data, and to providethe second data back to the client application (or another authorizedapplication) when subsequently requested (e.g., for decryption by thesecond application).

FIG. 7 shows a flow diagram of an exemplary process for using a secondapplication to decrypt data received by a first application and toprovide the decrypted data to a client application, in accordance withaspects of the disclosure. The steps of method 700 may thus be performedby one or more processors of a processing system (e.g., client computingdevice 104 and/or processing system 102 of FIG. 1 ) in response to afirst application receiving encrypted first data. Here as well, method700 may be applied to any suitable context. For example, the firstapplication may be an email application, calendar application, messagingapplication, word processing application, file storage application, orany other application in which decrypting content for use by a clientapplication may be desired. In some aspects of the technology, the firstapplication may comprise a webpage, and the client application maycomprise a web browser. In some aspects of the technology, the firstapplication, second application, and client application may all berunning on the same processing system (e.g., a client device such asclient computing device 104 of FIG. 1 ). In some aspects of thetechnology, the second application and client application may be runningon a client computing device (e.g., client computing device 104 of FIG.1 ), while the first application may be running on a remote computingdevice (e.g., server 102 a of FIG. 1 ).

In that regard, in step 702, the processing system configures a secondapplication such that the second application can decrypt the first datainto second data without the first application having access to thesecond data. As noted above, this may be done in any suitable way. Forexample, in some aspects of the technology, the first application maycomprise a webpage, and the second application may comprise an iframewithin the webpage. In some aspects, the iframe may further comprise anassociated decrypter (e.g., a function or program configured to performdecryption). In some aspects, the webpage and the iframe may havedifferent origins from one another, such as different web domains orsubdomains such that the first application (and any scripts runningthereon) do not have access to the DOM of the second application. Insome aspects of the technology, the second application may comprise asubwindow or subroutine configured such that the first application doesnot have access to the second data once it is generated by the secondapplication.

In step 704, the first data is received at the second application. Thesecond application may receive the first data from the first applicationor some other application.

In step 706, the second application decrypts the first data to generatethe second data. The second application may comprise a decrypter fordecrypting the first data into the second data, or may be configured tocall a separate decrypter application to perform this task.

In step 708, the second application provides the second data to a clientapplication. The second application may do this in any suitable way,such as by outputting the second data to a display or speaker associatedwith the processing system, by prompting the client application todownload the second data, by providing the second data in a format suchthat it can be displayed to the user by a client application (e.g., asHTML content to be displayed on the user's web browser), etc.

Unless otherwise stated, the foregoing alternative examples are notmutually exclusive, but may be implemented in various combinations toachieve unique advantages. As these and other variations andcombinations of the features discussed above can be utilized withoutdeparting from the subject matter defined by the claims, the foregoingdescription of exemplary systems and methods should be taken by way ofillustration rather than by way of limitation of the subject matterdefined by the claims. In addition, the provision of the examplesdescribed herein, as well as clauses phrased as “such as,” “including,”“comprising,” and the like, should not be interpreted as limiting thesubject matter of the claims to the specific examples; rather, theexamples are intended to illustrate only some of the many possibleembodiments. Further, the same reference numbers in different drawingscan identify the same or similar elements.

1. A computer-implemented method comprising: receiving, by one or moreprocessors of a processing system, first configuration data from a firstapplication identifying how to encrypt content of a message beingcomposed; sending, by the one or more processors, a request to a secondapplication to create an encryptor based on the first configurationdata: receiving, by the one or more processors, the encryptor from thesecond application; sending, by the one or more processors, secondconfiguration data to the first application indicating a readiness toaccept the content of the message to be encrypted; receiving, by the oneor more processors, the content of the message from the firstapplication for display to a user by a client application; andencrypting, by the one or more processors using the encryptor, thecontent of the message.
 2. The method of claim 1, wherein the contentcomprises text, one or more files, or both the text and the one or morefiles.
 3. The method of claim 1, wherein the first application is anemail application, calendar application, messaging application, or filestorage application.
 4. The method of claim 1, wherein the firstapplication comprises a webpage.
 5. The method of claim 4, wherein thesecond application comprises an inline frame within the webpage.
 6. Themethod of claim 5, wherein the webpage is from a first origin and theinline frame is from a second origin.
 7. The method of claim 6, whereinthe first origin and the second origin represent different web domains.8. The method of claim 7, wherein the first origin and the second originrepresent different web subdomains of a common web domain.
 9. The methodof claim 1, wherein the second configuration data identifies how todecrypt the encrypted content.
 10. The method of claim 1, wherein theclient application comprises a web browser.
 11. The method of claim 1,further comprising: sending, by the one or more processors, theencrypted content of the message to the first application.
 12. Acomputer-implemented method comprising: receiving, by one or moreprocessors of a processing system, configuration data from a firstapplication identifying how to decrypt content of an encrypted message;sending, by the one or more processors, a request to a secondapplication to create a decryptor based on the configuration data:receiving, by the one or more processors, the decryptor from the secondapplication; sending, by the one or more processors, an indication ofreadiness to accept the content of the of the encrypted message to thefirst application; receiving, by the one or more processors, the contentof the message from the first application; and decrypting, by the one ormore processors using the decrypter, the content of the message fordisplay to a user by a client application.
 13. The method of claim 12,wherein the encrypted content comprises text, one or more files, or boththe text and the one or more files.
 14. The method of claim 13, whereinthe first application is an email application, calendar application,messaging application, or file storage application.
 15. The method ofclaim 12, wherein the first application comprises a webpage.
 16. Themethod of claim 15, wherein the second application comprises an inlineframe within the webpage.
 17. The method of claim 16, wherein thewebpage is from a first origin and the inline frame is from a secondorigin.
 18. The method of claim 17, wherein the first origin and thesecond origin represent different web domains.
 19. The method of claim17, wherein the first origin and the second origin represent differentweb subdomains of a common web domain.
 20. The method of claim 12,wherein the client application comprises a web browser.